Summary of our deployment adventure

After the redeployment, the buoy has been sending the data from the sensors.  It was a close call.  We had a one day window of repairing and troubleshooting any issues, and yesterday was our last day at the station.  Looking back, everyone came to help to resolve issues that we faced.  We really appreciate Keith, Jessica and Andy from UCSB and our software/hardware team - Matt, John, Sameer, and Gesuri.  It was a great team effort.  We could not have done this without the team.

This study will enable the scientists to compare different types of ocean acidification sensors in multiple dimensions - cost of operation, resolution and precision of the data samples, maintenance cost, duration of the maximum deployment period and etc.  From the technical point of view, we demonstrated the feasibility of our approach to building a smart buoy controller using DataTurbine, a Droid phone, an inductive modem, long distance wireless and Bluetooth networking.  The Android phone controls the underwater sensors using the Bluetooth and the inductive modem technology.  After the data is collected, the phone communicates with the wireless radio in the buoy using the Wifi signal.  The wireless radio also communicates with the shore side radio, and the data is sent to the shore side computer through the paired wireless radios.

As promised, we will describe our troubleshooting experience.  Going back to the first deployment time, we found out that the buoy was not communicating. The next morning, Andy, Jessica and I went out on a boat to the buoy.  We had two suspicions.  Either the antenna connector was broken, or the steel casing and the aluminum plate were absorbing all the RF signals inside the buoy, keeping the Android phone from communicating with the wireless radio, which is mounted on the opposite side of the quarter inch aluminum plate.  The boat circled around the buoy, checking the strength of the Wifi and the Bluetooth at various spots.  We scanned and found the Bluetooth devices mounted on the OSDT Sensor Pod.  However, the Wifi signal was very poor.  Andy held the buoy steady and pushed down the wire into the connector - it was changing from nothing to poor.  Our primary suspicion seemed to be right that the connector went bad.  The bad connector did not resolve our second concern, but since the Bluetooth and the Wifi signals are on the same frequency spectrum around 2.4 GHz, we were optimistic about the Android phone communicating with the wireless radio inside the buoy.

Soon after, Keith, Andy and Jessica pulled the whole buoy out of the water.   Keith took the broken antenna cable to the local expert, and got it fixed.  Later that evening, we tested the antenna and confirmed that it was working properly.  The next morning, we reassembed the buoy and tested the wireless communication inside the buoy - at this point, our two networking concerns were resolved.  After going through the debugging process, we redeployed the buoy back into the water, and our first data point was received as shown in the last blog.

Currently, all of the sensors except the CO2Pro have been communicating with the buoy.  When we pulled the buoy out of the water, we noticed this problem by going through the data collection on the phone.  Our first suspicion to this problem was the SBE44.  When Keith and Jessica redeployed the buoy, they also relocated the SBE44, and checked the pump in the CO2Pro - it was pumping water into the sensor.  Currently, we don't know exactly where the problem lies, but at this point, we will let it operate and collect the data samples internally for further studies in comparing these cutting edge ocean acidification sensors.

Keith about to mount the buoy to the boat for the redeployment.  The black taped part is where the cable fix happened.

This system still needs further tuning and improvements.  This was our first pod deployed in the water.  We had a couple of hiccups - the charger problem and the antenna replacement.  We learned various aspects to consider when building the system - deployment process, physical/networking condition inside the buoy, designing the debugging capacity into the system, and troubleshooting it while it is in the water, writing down the exact list of check points during the deployment, etc.   The CO2Pro sensor still needs to be better integrated into the system.  However, all in all, we found our adventure to be successful.

Returning the lab back to the assistant cat.

We will summarize our experiences with a paper and an oral presentation at the International Coral Reef Symposium in Cairns, Australia http://www.icrs2012.com/.  I hope to see you there!

Please check our website (http://www.dataturbine.org/) for future updates on this project.

Success

We knew it would be an adventure - and it was!

There's not substitute for real field tests.  We learned a lot.

The networking problem is solved.  The antenna connector was the problem as suspected.  We enlisted the help from the local expert (Merci, Les), and got it fixed.  The system sent the first data points (please see the photo below). We demonstrated the feasibility of the DROID DataTurbine system and the use of Bluetooth and wireless networking (both in the buoy and between the buoy and the shore).

Plotting the first data points using plot.jar that comes with DataTurbine installation

There are more photos and stories to tell, but we will make today's blog short because I need to start packing - we move out at seven a.m. tomorrow.  

Redeploying the buoy after the fix (the yellow buoy is towed  to the red floating marker)

Thank you again to everyone who has helped us in Moorea, especially Keith, Jessica and Andy.

D day - deployment day

I have a lot to catch up.  I have been very busy last two days.  We successfully deployed the sensors and the buoy today, but we are experiencing a network problem currently.  We think it could be the antenna cable connector or the Wifi network inside the buoy.  We will figure this out soon.

As mentioned before, last four days, we tested the OSDT Sensor Pod in the lab - turning off the Wifi and the Bluetooth networks to see how it behaved during the failures.  If the sensors had the on-board memory to cache the data, the system grabbed these past samples on its next polling time.  Basically, the system kept collecting the data from the sensors whenever it could, and it behaved robustly despite those failures.

The first version of the BOB

All the electronics are taken out.

We designed our board to fit snugly on the mounting plate.  It upgraded the solar charger, and put solid power supply to all the electronic equipment.  Please see the photo below.

Tony, Andy and Neil (director of the Gump station) discussing the OSDT Sensor Pod and the ocean acidification

During this testing phase, Neil Davies dropped in to discuss our ocean acidification project.  He is the director of the UCB Gump research station, and he has numerous contacts.  He is aware of various projects, and he mentioned that the neighboring French scientists would be interested in our studies.

After his visit, we set out to test the networking gear with the antenna.  During this process, Tony got into an accident.  While he was carrying the top of the buoy (see the picture above) out to a boat, he stepped into an unstable floating surface at the dock and fell.  He is bruised, but not broken.  He is recovering, and we wish him the speedy recovery.  During the fall, the antenna on the buoy broke.  Since we brought a tester antenna, we can replace the antenna, but the original antenna had a special connector to the buoy.  This connector has a specially made pin to fit into the female socket.  Since the copper wire from the antenna cable was too thing, we soldered around it to make it thicker.  Then, we put the electrical tape and liquid tape around the connector.

Broken antenna

Special connector to the buoy (connects at the surface of the buoy)

The original antenna and the tester antenna

The tester antenna is less than half its length of the original antenna.  We then went out to the water and tested the radios.  From the shore to the buoy, the network worked well.  When we went twice the distance, the network started being not responsive.  This test indicates that the tester antenna is sufficient for our deployment.  

Yesterday, we mounted the OSDT Sensor Pod onto the buoy (see the photo above).  It is bolted down firmly.  The phone charger created an extra space on the side, but the holder could be rotated to fit it just right.  All in all everything fitted well.  All the existing interface wires (for IMM, Wifi, solar panels and batteries) were reused.  We also taped all the cables and the instruments to protect them from the fouling.  

The OSDT Sensor Pod mounted to the buoy

Then, the deployment began this morning.  We had four people in our team: Keith, Jessica, Andy and me.  We carried out the sensors and the buoy to the dock.  It takes tremendous efforts when putting the buoy and the sensors into the water.  The two golf cart batteries alone probably weighs over fifty pounds.  Then, rotating and fitting them into just the right place take precision and strength.  When deploying the sensors, CO2Pro had a limited window of forty minutes when it could be out of the water for the deployment.  Otherwise, the pump will start and get burned in the air.  So, we coordinated our time with such constraints.

Keith - Bolting down the top of the buoy into the body.

In the photo above, notice that the new antenna wire is wrapped around the pole of the buoy, then connects through the special connector.

After assembling the buoy, we put the sealant around the edges, and deployed the sensors at the bottom of the reef while the sealant dried.  In this study, we want to compare the data across different ocean acidification sensors at the same area.  Through this project, we not only provide the real-time data to the scientists, but also want to allow the scientists to compare the various aspects of the different types of sensors - precision, cost, durability, maintenance requirements and etc.  The below photos show the sensor deployment process.  I enjoyed participating in this challenging process. During the dive, I brought down the sensor, helped installing one of the sensors and photographed the process.  They are deployed at the 59 ft deep.  The silt at the bottom made the deployment process challenging.  The water was murky (see the photos below).

Jessica adding SBE44 to the mooring line

Andy also mounting the SBE44 onto the mooring line.

Andy and Jessica - attaching the MBARI HRpH sensors onto the spider legs that are anchored to the bottom

The aerial view of all five sensors.  The SBE 44s are attached along the wire loop. 

After deploying the sensors, we came back and towed the buoy out to the site.  Then, Keith and Andy put the buoy in place by connecting the IMM line, mooring cable and two other joints.  .

Then, the buoy was deployed.

Although the deployment process was successful, we are not receiving the data on the shore side.  We suspect that the OSDT Sensor Pod is collecting the data from the sensors without the Wifi connection currently.  Tomorrow, we will troubleshoot this networking issue.

Testing and Tuning

Today was a great day.  This system is behaving as designed and we are confident about the upcoming deployment in Cook's Bay.  The ability to conduct full end-to-end system tests has been invaluable in teasing out subtle issues of timing and control. We are grateful for the opportunity to utilize the resources of the UC Berkeley Gump Station and the MCR LTER Network site to conduct these in-depth tests. We are especially grateful for the assistance of our UCSB collaborators: Andy, Keith, and Jessica. Although we slipped our original deployment schedule by 2 days, we are all feeling good that we had this time to perform additional testing and hardening of the system.  We have a number of updates (I've been too busy to blog...) and many people to thank, and one unexpected encounter with a notorious native nemesis: the poisonous Tahitian centipede (photos below).

As mentioned yesterday, Keith and Andy pulled the buoy out of the water and disassembled it so that we could replace the old data logger system with our new OSDT Android Sensor Pod. We designed the Sensor Pod board and electronics to fit into the existing mounting framework, so the "brain transplant" should be relatively straightforward.  However, there is still some physical engineering that will need to happen tomorrow (Tues) to adapt the buoy internal structure to accommodate the Sensor Pod, e.g., drilling new mounting holes and figuring out where to place all of the components.  

BOB's internal structure where we mount the OSDT sensor pod.

As mentioned in yesterday's blog, Jessica stopped by to prep the instruments for deployment.  This involves taping over the entire surfaces of the instruments to reduce the effects of fouling and to make post-deployment cleaning easier. Jessica will also be one of the key deployment divers - installing all of the underwater components.  Thanks, Jessica!

Update on Bluetooth error handling:

One of the tricky engineering tasks has been to build into the system enough robustness to handle all the vagaries of an ocean deployment.  Things behave very differently in the open water than the do in our lab at UCSD. For the last few days I've been reviewing the logic behind the Bluetooth network connections to make sure that everything would continue to work correctly even when there were unexpected errors.  After testing several approaches, I decided to add a few seconds of wait time before and after opening the Bluetooth connection.  I then ran a number of tests injecting errors into the system, verifying that everything is working perfectly.  This is still a tricky area, and we will probably modify our approach based on the experiences we acquire on this deployment. 

Update on networking:

Networking is tricky.  There are networking issues on the buoy (noisy channels in the IMM, Bluetooth communications between the Android phone and the IMM, and wireless communications between the phone and the buoy radio). Then there are wireless networking issues between the buoy and shore (for this first deployment we are concentrating on long-distance wireless radios.  We'll test the Iridium satellite and cellular phone networks on the next round of tests).  And none of these network connections are guaranteed to be stable. So our system has to be very robust to network disruptions, hiccups, and (quite honestly) unexplained phantoms. This is a very challenging environment for wireless networking -- a perfect testbed for our technologies. (On a related note -- the entire Internet connection was down for Gump Station, and perhaps all of Moorea, for over 8 hours today). This is another reason why it is so important to test our system under local conditions. It's impossible to replicate these conditions in our lab at UCSD.

Andy and Tony went on a SCUBA diving mission today to prepare the underwater mountings and cables. They took kitchen pot scrubbers and scoured the entire length of the mooring cable, down to 58 feet. This will ensure that we have good connections for the SBE44 inductive modem couplers for our deployment.  It sounds like hard work, but I think that they had a fun time.

Irma rounding up the centipede.

  

A reminder that we are in tropical Tahiti.  When showering today after a swim in the lagoon, I noticed a 6-inch centipede on the shower curtain.  These creatures are poisonous, mean spirited, fast and ugly. Fortunately we were able to enlist the help of Irma, an important staff member of Gump Station, to help us handle this beast. She is a native of French Polynesia and knew how to wrangle this menace into a water bottle. She then handed the bottle and centipede to me and suggested that I add alcohol and turn it into a souvenir. It is now on my desk. I'm wondering what customs will say when I show up at LAX with this...  

Tomorrow is another busy day.  We will continue to test and tune the system.  We will start the integration of the Sensor Pod into the body of the buoy (see photo in the beginning).  If all goes according to plan, then the launch date is Wed, 25 January. If it doesn't go according to plan, then Tony and I will consider pulling a Gauguin (disappearing into the interior jungles of Tahiti. :-) )

Deployment preparation

Things have been hectic here.  The plan was to deploy the system tomorrow, but we delayed it for both logistical and system debugging reasons.  We are still busy testing various aspects of the system.

The existing buoy is out of the water.  We are replacing some batteries and taping the instruments to protect them against the fouling in the sea water.  During this system test, we found a couple of bugs and fixed them as well.  They involved handling the Bluetooth connection failure and restarting the parts of the multi-threaded program.  We set up the test involving all the instruments with the radios and the computer.  The system test worked well.  Now, we are configuring the buoy and the shore side networking infrastructure into the station networks so that we can access the data remotely.

I have a few of photos to show the above progress, and we will post them tomorrow when I get a chance to download the photos off the camera.  Stay tuned.

Crunch time

The deadline for everything working together is tomorrow night.  We plan to let the system run over the weekend, and on Monday if everything is good, we will start deploying it in the water.  At this point, everything is working perfectly, although we have had serious challenges over the last two days.

When we arrived at the lab on Wednesday morning, the system was down, and the phone was not being charged.  After troubleshooting the system and confirming that everything was correct, we had a mystery.  So, I went online and discovered that other people have had  the same problem.  It turns out that a Verizon OS update caused the phone to not charge properly.  It is a bug in their system:

http://forums.androidcentral.com/motorola-droid-pro/147994-charging-problem.html

At this point, we sent out an SOS to our technical collaborators, Matt, John, Sameer and Gesuri.  Gesuri responded immediately with two suggestions: get a phone without the update (basically, buy a new phone) and get a phone charger that is powered by the cigarette lighter in a car (thanks Gesuri!!). So, Tony and I made an emergency run to the local phone shop in Maharepa.  After convincing the clerk to run a number of tests for us at the store (not trivial), we purchased both.  We returned to the lab and confirmed that the approach using the cigarette lighter charger worked.  However, now we had to integrate it into the system.  It required disassembling the charger and soldering new wires to it (see photo down below).

Tony soldering the wires onto the charger

The rest of the afternoon was spent confirming that the system worked fine.  Andy and Keith stepped by to discuss the status of the system and to make plans for the deployment in Cook's Bay off Gump station.  We agreed that we would test the system for the next three days, and if everything works well, then we will start deploying it on Monday morning.  This process will involve pulling the current system out of the water, reconfiguring it with the new OA sensors and the OSDT Sensor POD and deploying it back in the water.  If all goes well, we expect this process to take three days.

This week will be an exciting time!

Challenges

Last two days, we worked on getting the system up and running with all five sensors.  We had to resolve three issues while doing that.

When I came to the lab in the morning, I noticed that the battery in the phone was running low, and it wasn't charging.  Since the connector to the phone often come loose, I jiggled it to see if it was going to get lighted up.  It didn't.  I looked at it more carefully, and found that one of the soldered wires broke off.  We constructed the connector part using the microUSB connector from Sparkfun:

http://www.sparkfun.com/products/10031

Although it is a great pad for soldering wires onto it, the connector part did not fit snuggly to the Motorolla DroidPro phone.  Tony and I soldered the fallen wire back onto it, but the phone was still not charging.  Since the brain of the OSDT Sensor Pod is the phone, we had to improvise making a new power connector.  When programming and debugging, I typically connect the phone to the computer via the USB data cable because programming and debugging tools such as Eclipse and other Android tools provide excellent support.  This USB data cable was supplied when the phone was purchased.  Since it can also power up the phone, I cut the USB cable, and found four different colored cables there.  The below photo shows that the red and the black wires from the MicroUSB cable were twisted onto the red and the black wires from the power supply.  Before doing that, I measured and confirmed that the red is +5V and the black is ground by plugging the USB part of the cable into the laptop.  The other two cables were not used since they are for the data communication.

Wiring the MicroUSB end to the power supply in the OSDT Sensor Pod

The photo was taken before soldering and making it secure and neat.  The new connector fits better to the phone, and it has good insulation.

After fixing the cable, we realized that the battery for the whole system was running low.  Keith soon gave us the charger, and we fixed that problem quickly. 

Disassembling the SBE44, and setting the jumper to power up the external sensor.

In order to power up the sensor using the SBE44 battery, the jumper on the electronics board inside SBE44 needs to be set differently.  It requires disassembling the unit completely.  The manual does not describe this disassembling process in detail, but the key is using the long screw driver on one of the screws.  We disassembled it, set the jumper and put it back together.  The MBARI HRpH needs this power from the SBE44 because it does not have its own batteries/power supply.  

After resolving these three issues, the system started functioning well.  The OSDT sensor pod is now collecting the data from all five sensors in the system.  They are set to collect the data every hour.

In the late afternoon, Bob Carpenter dropped by to see the system.  He is one of the co-PIs.  His research focuses on the effects of the Ocean Acidification on the coral reef ecosystem.  One can read general information here:

http://www.physorg.com/news/2012-01-paradise-ocean-acidification.html

With Bob Carpenter from CSUN.

Tony and I explained how the hardware and the software pieces in the OSDT Sensor Pod work with the sensors.  Bob asked questions regarding the limitation of the system that can affect the deployment conditions.  He explained to us the possible deployment sites.  The buoy will be located inside the reef where there are no high powered waves.  It needs to be in the line of sight because of the radios.  After Andy arrives, Bob mentioned that we would conduct a site survey, a reconnaissance operation - I'm excited to go snorkeling in the candidate sites.

Starting tomorrow, we will start setting up the shore side system with the radios.  If the system works end-to-end (sensors to the shore side computer) with the full suite of sensors, we will start stressing the system by turning off the power of the radios and creating bad network conditions.

Testing the system with the entire suite of sensors

We left the system on overnight to test the system with the two sensors, the CO2Pro and the SeapHOx.  It did not miss a single data point.  We stopped the system, and added the rest of the sensors to the system - two MBARI HRpH sensors and one SeaFET sensor.

 From closest to the farthest - SeaFET, two MBARI HRpHs, CO2Pro, and then SeapHOx
Each sensor is connected to the SBE44 

After mating each sensor with the SBE44, the OSDT Sensor Pod was configured to run with the five sensors.

After a couple of hours, we noticed that there was an error.  This error did not stop the system - the system continued its scheduled operation.  When we run our test, we set up the system to record the activities of the whole system.  From the log, we found that the SeaFET had a large number of data points stored from the earlier test in San Diego.  The IMM line has a 8KByte limit, and returned the partial data - the other parts are lost.  This is a limitation forced by the IMM.  This caused the error in the parser, and correctly flagged it to be an error.  We do not expect this to happen during our deployment.  

Just as a side note, when trying to get to the log file, the Droid Pro was not being friendly to me.  The log file was stored in the SD card, and it would not mount to the Windows laptop.  It turns out that last month, the driver was changed, and there is a conflict in the USB driver.  Here is a way to resolve this issue:   

http://adminontherun.blogspot.com/2011/12/droid-pro-and-mass-storage-driver-issue.html

System integration and resolving timing issues

It's been sunny for last two days, only raining at night.  Everyone seems to be enjoying the nice weather, including the numerous noisy red junglefowl (feral chickens).

Red junglefowl, Gallus gallus, Coq Bankiva

We left the system on overnight.  The system kept collecting the data from the SeapHOx every hour - it collected 22 samples until we stopped it.  We integrated another sensor today - the CO2Pro.

The CO2Pro has its own quirkiness when it comes to communication. Every hour, the CO2Pro has about two minute window when it becomes responsive.  The rest of the time, the communication line is not responsive from the CO2Pro side.  In order to poll the sample data from the CO2Pro, the OSDT Sensor Pod will have to communicate during this two minute window.  The clocks in the sensor and the OSDT Sensor Pod should be synchronized so that they can coordinate with each other.  This is where the timing issue arises.

We are interfacing the CO2Pro through the SBE44 and the Inductive Modem Module (IMM), and then to the Android phone.  The Android phone will initiate a series of commands at a scheduled time, but enforcing it to be on time requires some trick in Android operating system (foreground and notification of services).  There is a sequence of commands that will be issued from the Android phone to wake up the Bluetooth to Serial modem, the IMM and the SBE44.  Each command also takes several seconds, and each response goes through data sanity checks.  After all these steps, the two devices can finally communicate with each other.  This series of commands take time, and it should be factored into the scheduler in the OSDT Sensor Pod.

There can be also other general time issues that need to be taken into consideration.

There are several different times.  For instance, the Android phone is typically set with the UTC time or the GPS time.  There is about 15 seconds difference between the GPS (satellite) time vs. the UTC time.  While the scientists often use the UTC time, some Motorolla Android devices use the GPS time instead of the UTC time.

http://code.google.com/p/android/issues/detail?id=5485

Another aspect of time is the timezone.  Timezone is calculated using the UTC (GMT) time:
http://en.wikipedia.org/wiki/Greenwich_Mean_Time

The local timezone is calculated using this standard.  There is a positive side of using this standard UTC time.  But, it is often not easy to use it.  For instance, if we are conducting all the tests in CA, it is easier to interpret the daily temperature fluctuation using the local time in CA. If we were to use the Pacific time, we also need to choose between the day light savings time (PDT) vs. standard time (PST).

Luckily, we can avoid most of these issues by setting all the clocks to follow one time.  As long as the two devices are synchronized with one standard, the above issues can be resolved.  

However, we also need to consider how to mitigate the effects of clock drift in the two different devices: the sensor and the Android phone.  If the two clocks can drift at the same rate (faster or slower), it won't cause any problems.  If they drift the same direction, but at different rates, it is somewhat okay.  However, if they drift in opposite directions at fast rate, we will have the most problem.  Not knowing which direction or the rate the two clocks will drift, we can then aim to collect the data from the CO2Pro right in the middle of the two minute window to give the most robustness/flexibility.  This is how we set our system.

One might propose resetting the clock in the sensor to the Android phone occasionally.  This is a great idea from protecting the system from clock drift.  However, CO2Pro does not readily support resetting the clock, and it requires a series of steps to go through.  If something goes wrong, it has high penalty.  If the system loses the window of opportunity to communicate with the sensor, then the system loses the communication with it altogether.  The programmer needs to be very careful in implementing such steps.  Since the IMM line is just a RX/TX serial line without any error checking, the data can get corrupted - we have observed the odd characters occasionally.  The programmer needs to build some type of robustness on top of the serial line.  We explored this process in the lab, but decided it to be a lower priority for now.  Just as a side note, the SeaFET and the SeapHOx support this resetting of the clock through a simple command, and they do not have this synchronization issue - the window.

At this point, our approach appears to handle the synchronization issues.  The CO2Pro sensor is now integrated into the system.  The OSDT Sensor Pod collects the data from the CO2Pro in the middle of the two minute window.  Tony led the efforts of physically connecting and setting up the additional SBE44 with the CO2Pro to the system.  The OSDT Sensor Pod is synchronized with the ProCO2, and it is now collecting the data from both the SeapHOx and the ProCO2.

We plan on adding the rest of the sensors into the system as a next step.

Initial testing of SeapHOx and CO2Pro sensors

Keith and Jessica from UCSB arrived, and we discussed the two phase plan.  I needed their help on getting the batteries and setting up the tanks (bin) of seawater.  They got us two bins of seawater along with the car/boat batterries.  I wish I had taken photos of them setting them up.  I will be more dilligent in taking photos.

We set up both the SeaphOx and the CO2Pro, and tested them.  Then, we moved on connecting the SeapHOx to the SBE44 with the laptop.  All the tests passed, and currently, the OSDT Sensor Pod is controlling the Bluetooth to Serial adapter, IMM, SBE44 and the SeaphOX  to collect the data.  We found slight discrepancy in format of the data, and fixed the software end to handle them correctly. 

We will continue testing the SeapHOx today and add the CO2Pro in the testing tomorrow.  Then, either we will add the whole stuie of sensors or set up the shore side infrastructure.  Either way, in about five days from today, we will have the complete set up in the lab.  We will then start conducting the network disruption/failure tests.

Rain rain

A picture of the solar panels for the water heater, right outside our bungalow.  The waterfall in the background is the result of the storm.  Not the best combination...

The rain has been pouring since we got here.  Except for the first night, we have not had hot water.  We notified the staff about this today, and they kindly fixed it in the rain - I can take a hot shower.

Tony and I went to the hardware store here to find out what tools, screws, and other miscellaneous items were available.  We expected not much from here, but we were pleasantly surprised with their selection.

This deployment has two phases - first phase is in the lab, and the second phase is in Cook's Bay off the Gump Station.  During the first phase, we will test out the system piece by piece, and then as a whole system, all in the lab.  We expect to catch and fix bugs, and make the system more robust during this period.  If all the essential tests pass, we will take the existing buoy out of the water, and replace the electronics in the existing buoy with the OSDT Sensor Pod.

We developed the drivers for both the pCO2Pro and the SeapHOx, and tested the parser part with the simulated data.  Testing them with the real sensors is the next step.  These sensors need to be in the water since they have pumps - otherwise, the pumps will burn out.  We will use big buckets to test them.

It's still raining.

Unpacking and setting up the lab

Tony and I started unpacking the day we arrived in Moorea.  We set up the lab as shown below.  From the visual inspection, all the electronic equipment looked okay.  When unpacking the pelican cases, we noticed that three of the boxes contained the TSA inspection slips.  The inspection officers did not seem to disassemble any of the sensors, but they unscrewed the screws on the Sensor Pod, the mounting points around the Seabird Inductive Modem Module (IMM).  We are missing three screws, but we brought whole bunch of extra screws, washers and etc.  We will be okay, but it's curious why they just unscrewed them, and did not put the screws back on.

Mostly unpacked

You might have noticed a walking cane in the photo.  I have sprained ankles and sore knees, and I have been walking with the cane...  Tony has been doing all the heavy lifting since the beginning of the trip.  Thank you, sir.  I owe you a bunch.

Disassembling the SBE44

Tony and I disassembled the SBE44s and put the Lithium batteries in them.  After putting the batteries in all of them, we started configuring them.  The configuration requires using the IMM.  The 9V battery we brought only had 4.8V - pretty much dead.  We took the 9V battery out from the multimeter and used it for this test.  Although there is no hardware or electronic store in Moorea, it is possible to get the standard sized batteries here - we got a new one from the market afterwards.

Testing the SBE44 (underwater inductive modem) with an assistant cat

Testing SBE44s, SeapHOx and SeaFET

We tested and configured all six SBE44s, SeaFET and SeapHOx.  All of them were fine except one SBE44.  We will need to replace the batteries in it.

In next few days, we will find a car battery and a charger, and test the Sensor Pod platform - hopefully, none of the hardware items got damaged.  It is still raining here.  We will also work on developing and testing the drivers for the PCO2Pro and the SeapHOx as well.

The adventure begins: on the way to Moorea, French Polynesia

On Thursday, January 5th, Tony and I got to the San Diego Airport commuter terminal.  We had over 450 lbs of luggage - 7 big suitcases.  I wish I took the photo of these suit cases. We were concerned that all the electronic equipment would raise trouble with the TSA - sensors, radios, cables, batteries, and etc.  We put the manuals with photographs and any supporting documents with the electronics to avoid any troubles.  Luckily, the trip went very well.

We did have to wait throughout the trip though.  We arrived at the SD airport around 9:30 a.m. for 1 p.m. flight, just to make sure that our extra luggage items would be shipped properly, without a delay - for extra luggage, it was first come first serve.  The first flight, SD to LA was delayed for one hour (after we got boarded).  Then, our flight from LA to Tahiti was delayed for about two hours.  The above photos shows our flight, Air Tahiti Nui plane to Tahiti. By the time we started boarding, the sun was already setting.  Due to these delays, we arrived in Pappeete around 1 a.m.  Although we did not have any problems with customs, we waited for more than an hour in customs line.  We left all the research equipment pelican cases at the airport so that our colleague can help us transporting them the next morning.  By the time we arrived at our hotel, it was already 3 a.m. local time - 5 a.m. CA time.  We were quite tired.

The next morning, our colleague, Hinano picked us up at the hotel around 7:30 a.m. local time.  We went straight to the airport to pick up the research equipment that we left the night before.  We spent around 2 hours waiting for our luggage to come out.  Again, no problem, but just long waiting time.  Then, we took a ferry to Moorea.  It started raining in Moorea, but we were quite happy that we got here safely.